User knows the URLs of the service web applications

In this use case, the user is aware of the url for the web applications to receive service.  The user does not care about the identity provider the web applications may use.

This is the classic SAML v2.0 SP initiated SSO.

The user does not really know who the identity provider is. The user accesses the first application which we will call SP1. The first application will redirect the user to an Identity Provider where the user will authenticate. After successful authentication, the user is redirect back to the service provider SP1. In another browser tab, the user accesses another service application which we call SP2. The user is now seamlessly logged into SP2.

User authenticates to a central web application and then accesses various service web applications

This is the IDP initiated SSO and falls under SAML v1.1. This is described in PicketLink SAML v1.1

The user accesses the central identity provider. The user is asked to authenticate. After authentication, the user is presented with a portal page where there are links to the various service providers.

User logs into the Desktop using Kerberos. He then accesses web applications hosted in the same domain

This is a typical enterprise use case. Examples include the user logging into Kerberos backed Windows Desktop or Linux Desktop or Mac Desktop. The authentication is provided by a Kerberos Domain Controller such as Microsoft Active Directory or Red Hat IPA Server. The user then accesses a few web applications and desires to have seamless SSO.

There are two options here:

Users from different domains need access to your applications

It is possible that there may be users (such as partners or employees from a merged company) who need access to your applications. In this case, the IDP authentication stack can make use of shared directories or services as part of the authentication process.
In this example, we have two domains, Domain A and Domain B.  In this situation, there can be distinct users. Users of Domain A use the applications which uses IDP of Domain A. Similarly users of Domain B use the applications backed by IDP of Domain B.

There may be cases, when users of domain A need to use applications in domain B. In this case, they are sent to IDP of Domain B. But the authentication stack of IDP-Domain B has JAAS login modules that try to validate the user against LDAP/Domain B, LDAP/Domain A, DB/Domain B, DB/Domain A.  Because of JAAS options - required, requisite,sufficient and optional, we can get the authentication and role generation to work. It is also possible that in the absence of direct access to the data stores in a different domain, facade services to the data stores can be provided which can be appropriately coded in the JAAS login stack.